The present invention is related to a computer bus system. More specifically, the present invention is related to ASB (advanced system bus) slave responses.
ASB Bus:
As a microprocessor implementing RISC (reduced instruction set computer) architecture, an ARM (advanced RISC machine) microprocessor is not designed to work within a multiple masters computer system. Yet, by having multiple masters and multiple slaves within a computer system, the computer system gains more versatility in the types of functionalities that can be performed. Thus, in order for an ARM microprocessor to reap various benefits (e.g., functional versatility) associated with having a multiple masters/multiple slaves computer system, the ASB bus was introduced. Typically within the ASB system, multiple masters and slaves are coupled to the ASB bus. The ASB bus allows and supports an ARM microprocessor to function as the part of a multiple masters/multiple slave environment. In particular, the ASB bus is a widely used microprocessor system bus for computer systems based on the ARM family of microprocessors. Furthermore, the nomenclature and concepts relating to the ASB system are explained in detail in xe2x80x9cAdvanced Microcontroller Bus Architecture Specificationxe2x80x9d published in 1997 by Advanced RISC Machines Ltd. The following discussion will also adapt the nomenclature of this reference.
Referring now to FIG. 1, a generic ASB system 100 is depicted as having: an ASB bus 110; two ASB masters A and B (e.g., ARM Processor, PCI (peripheral component interconnect) to ASB Masters etc.); two ASB slave devices X and Y (e.g., memory controllers, slave devices); an ASB decoder 105 (centralized decoder that selects a slave by asserting a device select signal, Dsel); and an ASB Arbiter 107 (arbitrates the bus among multiple masters). Furthermore, a PCI bus 120 is coupled to ASB bus 110 via slave Y. PCI bus 120 is coupled to devices such as PCI devices P and Q that run at slower speed than ASB system 100.
ASB decoder 105 performs the decoding of the data transfer addresses, then selects slaves according to the decoded addresses. ASB arbiter 107 ensures that only one bus master at a time is allowed to initiate data transfers. Masters A and B can initiate a read or a write data transfer. Only one master is allowed by arbiter 107 to access ASB bus 10 at one time. Slaves X and Y respond to a read or a write data transfer. Slaves such as X and Y signal back to the active master the success, failure or extension of the data transfer. Furthermore, when a data transfer is intended for a peripheral device such as PCI device Q, the slower speed of PCI device Q causes latency in slave Y""s responses to the data transfer. For this reason, slave Y can be called a lower xe2x80x9clatencyxe2x80x9d slave of ASB system 100.
Slave Responses within an ASB System:
Referring still to FIG. 1, a multiple masters/slaves system bus such as ASB bus 110 necessitates coordination of bus access among the masters and the slaves. Unfortunately, this bus access coordination in turn gives rise to many issues that, if unresolved, can lead to a congested and an inefficient bus architecture. One such issue is ensuring synchronous slave responses with respect to a data transfer. Specifically, in order for ASB bus 110 to function at high clock speed, slave responses need to be driven synchronously onto ASB bus 110. But certain slaves such as slave Y cannot easily respond synchronously because these slaves have slave response latency. Typically, slave response latency comes from slaves (e.g., slave Y) that are coupled to peripheral devices (e.g., PCI device Q) having slower processing speed compared to ASB bus 110.
In particular, certain slaves such as slave Y can constitute intermediary stations between a master such as the ARM microprocessor and a slower peripheral device such as PCI device Q. In order for the ARM microprocessor to communicate with slower peripherals without impacting the system performance, an intermediate xe2x80x9cagentxe2x80x9d such as slave Y is used as a slave of the ASB bus. This xe2x80x9cagentxe2x80x9d slave, traditionally called the xe2x80x9cbridgexe2x80x9d facilitates the communication between the ARM microprocessor (via the ASB bus) and the slower peripherals. Moreover, the slower peripherals can communicate with the ARM processor through such a bridge via a standard interface such as VPB, PCI, APB or their own customary interfaces. Common examples of these peripherals include devices like IDE (integrated drive electronics) disk controllers, UART""s (universal asynchronous receiver transmitter) etc., which are slow compared to the microprocessor system bus such as ASB bus 110.
As an example, referring still to FIG. 1, when master A accesses a slow device, such as PCI device Q that is coupled to slave Y, time is needed to compensate for the difference in speeds between master A and the slow PCI device Q. That is, when master A attempts to access the slow PCI device Q, this PCI device Q might not be able to respond to master A immediately. Also, the speed difference between ASB bus 110 and PCI bus 120 creates uncertainty in the timing of slave responses for slave Y. As latency is created at slave Y (hence xe2x80x9clatencyxe2x80x9d slave), driving slave responses synchronously becomes less straightforward. Also, traditionally, the slave devices on ASB bus 110 do not synchronize the incoming signals from a master. Thus, various prior art approaches were implemented to achieve synchronous slave responses in view of these considerations.
Prior Art Implementations:
In order to synchronize slave responses in view of these conditions, the prior art slave devices either a) drive the outputs combinatorially or b) insert wait states. The former method is a bad design practice because it can cause glitches in the timing of ASB bus 110. Moreover, this former method is slow to execute; thus, it limits the speed of operation of the bus. The latter method of inserting wait states affects the system performance and bus throughput. Specifically, in the prior art ASB systems, the ASB slave devices rely on a device select signal xe2x80x9cDselxe2x80x9d (driving by address decoder 105) to make decisions for that clock cycle in which they are addressed. Dsel is a combinatorial decode of 32 address lines generated by the address decoder and hence is a late arriving signal. Typical timing numbers for a 100 MHz ASB bus slave is shown in FIG. 2.
Referring now to FIG. 2, Dsel 251 is driven on the rising edge of Bclk 250 in cell 203 and can take as many as 4 nano seconds to be valid (see TisDsel 222, the input setup time for Dsel). The slave device sampling this Dsel 251 has to use this Dsel signal to drive slave responses. These slave responses are comprised of Bwait 255, Blast 257 and Berror 259 signals that are sampled in the next rising edge of Bclk 250 as shown in FIG. 2. This means that the raw Dsel 251 signal needs to be used as such to make a decision to drive the Bwait 255, Blast 257 and Berror 259 signals even while inserting wait states to achieve synchronous slave responses.
This prior art implementation of synchronous slave responses has at least the following drawbacks. First, use of raw Dsel 251 implies that there can be no high-speed ASB cycles without wait states. Second, registering Dsel 251 inplies that there needs to be at least one clock wait state which results in low performance of the ASB bus. Third, driving Bwait 255, Blast 257 and Berror 259 based on raw Dsel 251 with some combinatorial logic to make the decisions implies that the ASB system can only run at a limited speed. Fourth, using the above implies that the outputs can glitch, hence providing a very dangerous scenario in terms of reliability. Fifth, use of combinatorial outputs makes timing analysis difficult. All these drawbacks can deleteriously affect the performance of the ASB bus. In all, the ASB bus performance relies on synchronous slave responses. Unfortunately, in the prior art implementations, driving slave responses synchronously for certain latency slaves ironically can deleteriously affect the ASB bus performance. Nevertheless, if synchronous slave responses can be achieved for these xe2x80x9clatencyxe2x80x9d slaves without deleteriously affecting the ASB bus performance, then the ASB bus performance can be maintained or even improved.
Thus, a need exists for a method of synchronous slave responses without inserting too many wait states that slow down high speed ASB clock cycles. Also, a need exists for a method of synchronous slave responses without needing to have a one clock wait state. Furthermore, a need exists for a method of synchronous slave responses without relying on some combinatorial logic to make the decisions for the slaves to be able to drive slave responses. Further yet still, a need exists for a method of synchronous slave responses without risking any glitches that prevent the proper functioning of the ASB bus. In addition, a need exists for a method of synchronous slave responses without making timing analysis difficult on account of the combinatorial outputs.
Fortunately, as will be explained in the following pages, the present invention successfully answers all of the needs stated above with a new approach to synchronize slave responses. With this new approach, the present invention improves the throughput of an ASB system.
The approach described in this invention uses a predictive scheme whereby the slave device uses the wait state inserted by the address decoder on the ASB bus to set up synchronous slave responses, and hence lead to the ability of the ASB bus to operate at higher speeds.
The present invention is drawn to a computer implemented method and system for synchronously driving slave responses onto an ASB (advanced system bus) bus. In particular, by synchronously driving slave responses, the present invention improves the efficiency of bus access coordination for multiple masters and slaves. Until the present invention, synchronous slave responses are either preceded by error prone combinatorial decoding or time consuming wait state insertions onto the ASB bus. In contrast, the present invention drives synchronous slave responses onto the ASB bus without combinatorial decoding and without inserting wait states onto the ASB bus. Rather, the present invention enables the slave devices on an ASB bus to predictively assert the ASB slave bus control signals (Berror, Blast and Bwait). This predictive assertion is implemented by taking advantage of the presence of a wait state inserted by a decoder and/or the address only cycles before actual transfer cycles inserted by ASB bus masters. In doing so, the present invention facilitates the control signals to be asserted synchronously, thus enabling future ASB slave devices to run at higher speeds. Furthermore, in combination with the retract cycles, the ASB slave devices enable much higher system throughput compared to slave devices that would have inserted wait states until the pending transfer is completed.
In particular, the present invention drives slave responses synchronously without inserting any wait states. Furthermore, the present invention drives slave responses synchronously without relying on some combinatorial logic to make the decisions for the slaves to be able to drive slave responses. Further, the present invention drives slave responses synchronously without risking any glitches that prevent the proper functioning of the ASB bus. In addition, the present invention drives slave responses synchronously without using combinatorial outputs to complicate timing analysis. In all, the present invention overcomes the problems of the prior art approach in driving slave responses onto an ASB bus.
In one preferred embodiment of the present invention, a slave asserts slave responses synchronously without inserting any wait state onto an ASB bus. On the one hand, in response to a read transfer from a ASB master, an ASB slave predicts the read transfer to be intended for a device attached to the ASB slave if the device is ready to return read data. In particular, the ASB slave substantiates this prediction by asserting read slave responses during the decoding cycle prior to a device select signal (Dsel) being driven onto the ASB bus. On the other hand, in response to a write transfer from the ASB master, the ASB slave predicts the write transfer to be intended for the device attached to the ASB slave. In particular, the ASB slave substantiates this prediction by asserting write slave responses during the decoding cycle prior to Dsel being driven onto the ASB bus.
In both scenarios predicted by the ASB slave, Dsel is utilized to validate these two predictions. That is, the read slave response driven by the ASB slave does not enter the ASB bus when the device select signal does not select the ASB slave. Also, the write slave response driven by the ASB slave does not enter the ASB bus when the device select signal does not select the ASB slave. In so doing, when these two predictions are valid, the ASB slave can synchronously drive appropriate slave responses onto the ASB bus without inserting wait states. Moreover, when these two predictions are not valid, wrong slave responses are prevented from entering the ASB bus. By not relying exclusively on Dsel to determine and drive slave responses onto the ASB bus, but rather relying on Dsel to validate asserted slave responses from the slave en route to the ASB bus, the present invention answers the existing needs of the ASB bus as stated before.
These and other objects and advantages of the present invention will no doubt become obvious to those of ordinary skill in the art after having read the following detailed description of the preferred embodiments which are illustrated in the various drawing figures.